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1 REMARKS 

2 These remarks follow the order of the paragraphs of the office action. Relevant portions of the 

3 office action are shown indented and italicized. 

4 DETAILED ACTIONS 

5 This is a Non-Final Office Action Correspondence in response to U.S. Application No. 

6 10/776297 filed on February 11, 2004. Claims 1-25 are pending. 

1 Claim Objections 

8 1. Claims 5, 9, 17, and 23 are objected to under 37 CFR 1. 75(c), as being of improper 

9 dependent form for failing to further limit the subject matter of a previous claim. 

10 Claim 17 discloses that the method of claim 1 can be used and hence fails to further limit 

1 1 claim 1. 

12 In response, the applicants respectfully states that claim 17 is amended to overcome the objection 

13 and claim 17 is allowable. 

14 Claims 5, 9, and 23 disclose products to effect the steps or functions of the claims they 

1 5 depend on and hence fail to further limit the claims they depend on. Applicant is required 

16 to cancel the claim(s), or amend the claim(s) to place the claim(s) in proper dependent 

17 form, or rewrite the claim (s) in independent form. 



18 In response, the applicants respectfully states that claims 5, 9, and 23 are dependent Beauregard 

19 claims protecting the software for implementing the method and apparatus. This claim format 

20 was successfully used in many issued patents for several years. 

21 In order to be fully compliant Claims 5, 9, and 23 are amended in format to overcome the 

22 objection and to overcome the objection and Claims 5, 9, and 23 are allowable. 



23 2. Claims 6, 7, 8, 12, 1 7, 18, 20, and 25 are objected to because of the following 

24 informalities: 

25 Claims 6, 12, 17, 18, 20, and 25 should be corrected so that semicolons are used in place 

26 of commas where appropriate. 
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1 Claims 7 and 8 should include an AND or an OR after the last semicolon. 

2 Appropriate correction is required. 

3 3. Claims 17 and 21 are objected to because of the following inf ormalities: 

4 Claim 1 7 contains "at least one of terminology that indicates an OR relationship 

5 between limitations. However applicant uses AND terminology. For example, in claim 

6 17, infrastructure characteristics change, and should be corrected to read infrastructure 
1 characteristics change, or Appropriate correction is required. 

8 In response, the applicants respectfully states that Claims 6, 7, 8, 12, 17, 18, 20, and 25 are 

9 amended to overcome the objection and Claims 6, 7, 8, 12, 17, 18, 20, and 25 are allowable. 

1 0 Claim Rejections -35 USC § 112 

1 1 4. Claims 2, 3, and 21 are rejected under 35 U.S.C. 112, second paragraph, as being 

12 indefinite for failing to particularly point out and distinctly claim the subject matter 

1 3 which applicant regards as the invention. 

14 5. Claim 2 recites the limitation "wherein the step of obtaining "a" Service Environment 

1 5 Model ". However, since claim 2 refers to the Service Environment Model as disclosed in 

16 claim 1, claim 2 should appropriately read wherein the step of obtaining "the " Service 

17 Environment Model or should otherwise be modified to include indication that the 

1 8 Service Environment Model as disclosed in claim 2 is the same Service Environment 

19 Model disclosed in claim 1. There is insufficient antecedent basis for this limitation in the 

20 claim. 

21 6. Claim 3 recites the limitation "said Service Environment Model description ". 

22 However, no Service Environment Model description is introduced in claim 3 or 

23 described in any previous claim that claim 3 depends on. There is insufficient antecedent 

24 basis for this limitation in the claim. 

25 7. Claim 21 recites the limitation "said step of generating" . However, no step of 

26 generating is introduced in claim 21. Furthermore, claim 21 is an apparatus claim; it is 

27 unclear how an apparatus claim contains steps. There is insufficient antecedent basis for 

28 this limitation in the claim. 



29 In response, the applicants respectfully states that Claims 2, 3, and 21 are amended to overcome 

30 the rejections under 35 U.S.C. 112, second paragraph, so that each is definite and particularly 
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1 points out and distinctly claims the subject matter which applicant regards as the invention. Thus, 

2 Claims 2, 3, and 21 are allowable. 

3 Claim Rejections -35 USC § 102 

4 8.. The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that 

5 form the basis for the rejections under this section made in this Office action: 

6 A person shall be entitled to a patent unless - 

1 (e) the invention was described in (1) an application for patent, published under section 

8 122(b), by another filed in the United States before the invention by the applicant for 

9 patent or (2) a patent granted on an application for patent by another filed in the United 

10 States before the invention by the applicant for patent, except that an international 

1 1 application filed under the treaty defined in section 351(a) shall have the effects for 

12 purposes of this subsection of an application filed in the United States only if the 

1 3 international application designated the United States and was published under Article 2 

14 1(2) of such treaty in the English language. 

15 9. Claims 1-6, 9-14, 19, and 21-25 are rejected under 35 U.S.C. 102(e) as being 

16 anticipated by U.S. Patent No. 7,050,807 filed on June 12, 2000 by Osborn (denoted 

17 herein as "Osborn"). 

18 In response, the applicant respectfully states that Claims 1-6, 9-14, 19, and 21-25 are not 

19 anticipated by the invention of Osborn. The present invention, claimed in Claims 1-6, 9-14, 19, 

20 and 21-25 provides for: 

21 "provisioning and managing computing services in a computing utility system. It receives 

22 as an input an infrastructure independent description of a set of requirements on the new 

23 desired state of a computing service. It uses a knowledge plane to represent the 

24 infrastructure. The method generates a Concrete Model that describes a resource structure 

25 that refines the input and is implementable over the infrastructure. It then generates and 

26 possibly executes provisioning actions to create an identical resource structure on the 

27 infrastructure. The method can be used to create new computing services, to destroy 

28 existing computing services, to modify the resource combinations allocated to a 

29 computing service, or the configuration of these resources. Provisioning actions can be 

30 executed immediately, or saved and executed later, and possibly many times. Provisioning 

3 1 actions may be regenerated using the method whenever infrastructure characteristics, or 

32 the service requirements change." 
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1 Thus, the present invention in Claims 1-6, 9-14, 19, and 21-25 are directed to provisioning and 

2 managing computing services in a computing utility system by generating a Concrete Model that 

3 describes a resource structure that refines the input and is implementable over the infrastructure. 

4 It also is concerned with generating and executing provisioning actions to create an identical 

5 resource structure on the infrastructure. 

6 It is noted, that the manageability model for Web services endpoint is defined as concrete models 

7 in UML using the topics and aspects concepts, without implying any particular implementation or 

8 locus of implementation. Appropriate manageability interfaces are defined based on the UML 

9 manageability models. The Unified Modelling Language (UML) is an Object Management Group 

10 (OMG) standard for modelling software artifacts. 

1 1 Whereas, the cited art to Osbom, US Patent 7,050,807, filed: June 12, 2000, is entitled: 



12 "Hardware resource identifier for software-defined communications system". The Osborn abstract 

13 reads: 

14 "A hardware resource identifier (19) recognizes hardware resource dependencies in a 

15 multi-channel communications system. Initially, system communications domains (D1-D4) 

16 in which system hardware resources are located are identified. Next, managed hardware 

17 resources, hardware resource groups and hardware resource group boundaries among the 

18 system hardware resources are identified. Association labels are then assigned to the 

19 system hardware resources to identify relationships, if any, between the system hardware 

20 resources and external hardware, to discern redundant resources within respective ones of 

21 the hardware resource groups, and to characterize dedicated coupling between individual 

22 ones of the system hardware resources. An abstract resource specification (78) is then 

23 interpreted to locate available system hardware resources, as organized into the system 

24 identified communications domains and the identified hardware resource groups, to enable 

25 maximum preservation of most functional and least available hardware resources during 

26 hardware resource allocation". 

27 Thus, Osborn is directed to a hardware resource identifier (19) recognizes hardware resource 

28 dependencies in a multi-channel communications system. Osborn is concerned with assigning 
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1 labels to system hardware resources to identify relationships, between the system hardware 

2 resources and external hardware, to discern redundant resources within respective ones of the 

3 hardware resource groups, and to characterize dedicated coupling between individual ones of the 

4 system hardware resources. This is not related to the present invention as claimed in Claims 1-6, 

5 9-14, 19, and 21-25. 

6 Osborn is apparently not concerned with provisioning and managing computing services in a 

7 computing utility system by generating a Concrete Model that describes a resource structure that 

8 refines the input and is implementable over the infrastructure. Osborn is also not concerned with 

9 generating and executing provisioning actions to create an identical resource structure on the 
10 infrastructure. Thus, Claims 1-6, 9-14, 19, and 21-25 are allowable over Osborn. 



11 10. As for claims 1 and 21, Osborn discloses a method comprising (an apparatus 

12 comprising means for) generating a Concrete Model, said Concrete Model describing a 

13 structure of resources implementable over a computing utility infrastructure, and 

14 satisfying a set of service requirements, said step of generating comprising the steps of: 

1 5 (means for) obtaining a Service Environment Model of a service environment, said 

1 6 Service Environment Model describing a set of requirements on a new desired state of 

1 7 said service environment (Osborn discloses obtaining an object specification, or 

18 application specification, with virtual application objects of an application which 

19 describe requirements associated with the application, see column 3 lines 44-59, column 

20 4 lines 15-23, and Figure 2 reference number 68); 

21 (means for) getting an Infrastructure Model describing both resources and an 

22 organization of the resources in the computing utility infrastructure, said Infrastructure 

23 Model is encapsulated in a knowledge subsystem (Osborn discloses obtaining a hardware 

24 abstract resource description, or hardware specification, in a system describing both 

25 resources and an organization of the resources, see column 3 lines 17-44 and Figure 8); 

26 In response, the applicants respectfully states that exception is taken with the alleged teaching of 

27 the elements of claim 1 by Osborn. Claim 1 reads: 

28 1 . A method comprising generating a Concrete Model, said Concrete Model describing a 

29 structure of resources implementable over a computing utility infrastructure, and satisfying 

30 a set of service requirements, said step of generating comprising the steps of: 
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1 obtaining a Service Environment Model of a service environment, said Service 

2 Environment Model describing a set of requirements on a new desired state of said service 

3 environment; 

4 getting an Infrastructure Model describing both resources and an organization of the 

5 resources in the computing utility infrastructure, said Infrastructure Model is encapsulated 

6 in a knowledge subsystem; and 

7 forming the Concrete Model describing a resource structure such that said Concrete 

8 Model refines the Service Environment Model and is mappable to said knowledge 

9 subsystem . 

10 Exception is taken with the alleged teaching of Osborn as stated above, in the following: 

1 1 (Osborn discloses obtaining an object specification, or application specification, with 

12 virtual application objects of an application which describe requirements associated with 

13 the application, see column 3 lines 44-59, column 4 lines 15-23, and Figure 2 reference 

14 number 68); 



15 Maybe. But, these "object specification, or application specification, with virtual application 

16 objects of an application which describe requirements associated with the application," apparently 

17 have no relation to claim 1 elements. Some words and phrases may be similar to words and 

18 phrases in claim 1, but are not related to the steps of claim 1 . A review of Osborn fails to show 

19 Osborn teaching alleged in the office communication 

20 For example, the cited Osborn portion column 3 lines 17-44 reads: 



21 The hardware resource manager 18 is responsible for allocating hardware resources to 

22 system applications so that the least available and most functional of the available 

23 hardware resources 14 are not allocated until all options for using more available and/or 

24 less functional hardware resources for an application are exhausted. Details as to how the 

25 hardware resource manager 18 allocates hardware resources are given in co-pending 

26 application Ser. No. 09/586, 120 entitled Dynamic Hardware Resource Manager For 

27 Software-Defined Communications System, assigned to Motorola Corporation and 

28 incorporated herein by reference. The hardware resource manager 18 allocates hardware 
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1 resources to an application based on characteristics, or attributes, of available hardware 

2 resource such as, for example, resource capabilities, name, type, flavor, shared, version, 

3 and address characteristics stored in a hardware specification maintained on the system 

4 platform 12 and updated as hardware resources are added or removed, as well as on 

5 configuration characteristics tracked and generated by a hardware resource identifier 19. 

6 The hardware resource identifier 19 of the present invention then uses this characteristic 

7 hardware resource information to generate a hardware specification, graphically illustrated 

8 as an abstract resource specification (78 in FIG. 2), that identifies hardware resource 

9 constraints and interdependencies and that is used by the hardware resource manager 18 

10 to designate certain of the resources 14 as allocated resources 15. 

1 1 Applicants respectfully states that a review of the above fails to indicate concern with, anticipation 

12 or teaching of: 

13 any model; 

14 any Concrete Model; 

15 any computing utility; 

16 any computing utility infrastructure; 

17 any service; 

18 any service requirements 

19 any desire of satisfying a set of service requirements 

20 any Service Environment Model; 

21 any service environment; 

22 any step of generating to obtain a Service Environment Model of a service environment; 

23 any description of a new desired state of any service environment; 

24 any Infrastructure Model 

25 any Infrastructure Model describing resources and an organization of the resources; 

26 any computing utility infrastructure; 

27 any knowledge subsystem; 

28 any Infrastructure Model encapsulated in a knowledge subsystem; 

29 any step of generating a Concrete Model; 
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1 any Concrete Model that describes a structure of resources implementable over a 

2 computing utility infrastructure, and satisfying a set of service requirements, said step of 

3 generating comprising the steps of: 

4 Exception is also taken with the alleged teaching of the elements of claim 1 by Osborn of: 

5 (means for) forming the Concrete Model describing a resource structure such that said 

6 Concrete Model refines the Service Environment Model and is mappable to said 

1 knowledge subsystem (O shorn discloses generating an application abstract resource 

8 description describing a resource structure, see Figure 9, that is derived from the object 

9 specification mentioned above and is mapped to resources in the system, see column 3 

10 lines 60-67 and column 4 lines 1-14). 

1 1 The cited Osborn portion column 3 lines 60-67 reads: 

12 From information provided in the application specification 34, the application manager 16 

13 also creates an abstract resource description 72 including virtual hardware resource 

14 objects 74 which identify application hardware requirements, and which are transmitted to 

15 the hardware resource manager 18 and mapped at 76 in the abstraction layer 54 to the 

16 available system hardware resources 14, based on the hardware resource interdependency 

17 data in the abstract resource specification 78 generated by the hardware resource identifier 

18 19 of the present invention, to create the allocated hardware resources 15 (the object 

19 specification 68, the abstract resource description 72 and all other specifications necessary 

20 to define an application are subsets of the application specification 34). The objects 36 are 

21 then loaded onto the allocated hardware resources 15 through the abstraction layer 54 at 

22 38 to run the requesting application. The hardware resource identifier 19 applies hardware 

23 resource constraints and interdependencies as represented generally by the arrows 76 in 

24 the static specification stage 60 by interpreting the abstract hardware resource description 

25 72 to enable the available hardware resources 14 to be effectively allocated by the 

26 hardware resource manager of the present invention. 

27 The cited Osborn portion column 4 lines 1-14 reads: 

28 From information provided in the application specification 34, the application manager 16 

29 also creates an abstract resource description 72 including virtual hardware resource 

30 objects 74 which identify application hardware requirements, and which are transmitted to 
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1 the hardware resource manager 18 and mapped at 76 in the abstraction layer 54 to the 

2 available system hardware resources 14, based on the hardware resource interdependency 

3 data in the abstract resource specification 78 generated by the hardware resource identifier 

4 19 of the present invention, to create the allocated hardware resources 15 (the object 

5 specification 68, the abstract resource description 72 and all other specifications necessary 

6 to define an application are subsets of the application specification 34). The objects 36 are 

7 then loaded onto the allocated hardware resources 1 5 through the abstraction layer 54 at 

8 38 to run the requesting application. The hardware resource identifier 19 applies hardware 

9 resource constraints and interdependencies as represented generally by the arrows 76 in 

10 the static specification stage 60 by interpreting the abstract hardware resource description 

11 72 to enable the available hardware resources 14 to be effectively allocated by the 

12 hardware resource manager of the present invention. 

13 Applicants respectfully states that a review of the above fails to show any Osborn concern with, 

14 anticipation or teaching of: 

1 5 forming any Concrete Model; 

16 any Concrete Model describing a resource structure; 

17 any Concrete Model that refines any Service Environment Model; 

18 any Concrete Model that is mappable; 

19 any Concrete Model that is mappable to any knowledge subsystem; or 

20 any step of forming a Concrete Model describing a resource structure such that the 

21 Concrete Model refines the Service Environment Model and is mappable to said 

22 knowledge subsystem . 

23 Thus claim 1 and all claims that depend on claim 1 are allowable over Osborn. 

24 11. As for claim 2, Osborn discloses each and every limitation of claim 1. Osborn further 

25 discloses wherein the step of obtaining a Service Environment Model of the service 

26 environment includes receiving a description of a set of requirements on a new desired 

27 state of said service environment (Osborn discloses the object specification, or 

28 application specification, includes virtual application objects that describe requirements 
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1 on a new desired state of the service environment of the application, see column 3 lines 

2 44-59, column 4 lines 15-23, and Figure 2 reference number 68). 

3 In response, the applicants respectfully states that exception is taken with the alleged teaching of 

4 the elements of claim 2 by Osborn. A review of all the cited portions of Osborn fails to support 

5 the teaching of any of the claims 1-25 of this application. The cited portions are copied below to 

6 show that indeed the alleged teaching of the elements of each claim are apparently not in Osborn. 

7 Thus, all claims are allowable over Osborn, even when combined with the other references cited 

8 below, for obviousness purposes. 



9 The cited Osborn portion column 3 lines 44-59 reads: 

10 FIG. 2 is a more detailed block diagram of the topology of the system architecture of the 

1 1 multi-channel software-defined radio 10 shown in FIG. 1 . As shown, the architecture 

12 includes several functional layers, including an application object layer 50, a virtual 

13 hardware layer 52, an abstraction layer 54 and a physical hardware layer 56, as well as 

14 several application management stages, including a static specification stage 60, a 

15 hardware allocation stage 62, an object creation stage 64 and an application startup stage 

16 66. The functional layers 50-56 operate to load the application objects 36 onto the 

17 allocated hardware resources 15 based on the application specification 34, as well as the 

18 composite hardware specification provided by the hardware resource identifier 19 based 

19 on its processing of the static system hardware specification 40 provided with the system 

20 as well as its processing of the dynamic hardware discovery results. 

21 The cited Osborn portion column 4 lines 15-23 reads: 

22 The application object layer 50 includes the virtual application objects 35, which are in an 

23 object specification 68 and which identify software application objects 36 necessary to run 

24 a system application. The application manager 16 retrieves the identified application 

25 objects 36 from the application object libraries 37 based on the virtual objects 35 in the 

26 object specification 68 and loads the objects 36 onto the allocated hardware resources 15 

27 as indicated at 38. 
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1 This doesn't teach claim 2 elements. Thus clam 2 is allowable for itself and because it depends on 

2 an allowable claim. 

3 12. As for claim 3, Osbom discloses each and every limitation of claim 1. O shorn further 

4 discloses wherein said Service Environment Model description is independent of the 

5 computing utility infrastructure (Osbom discloses the object specification, or application 

6 specification, that does not depend on to the computing utility infrastructure, see column 
1 3 lines 44-59, column 4 lines 15-23, and Figure 2 reference number 68). 

8 The cited Osbom portion column 3 lines 44-59 reads as stated above. 

9 The cited Osbom portion column 4 lines 15-23 reads as stated above. 

10 In response, the applicants respectfully states that this doesn't teach claim 3 elements. Thus clam 

11 3 is allowable for itself and because it depends on an allowable claim. 

12 13. As for claim 4, Osbom discloses each and every limitation of claim 1. Osbom further 

13 discloses wherein said service environment is an entity taken from a group of 

14 entitiesconsisting of: a Web site, an on-line gaming service, a scientific computation 

1 5 service, an e-business service, a computing service (Osbom discloses a service 

16 environment for an application, see column 3 lines 60-67 and column 4 lines 1-14), and 

17 any combination of these. 

18 The cited Osbom portion column 3 lines 60-67 reads as stated above. 

19 The cited Osbom portion column 4 lines 1-14 reads as stated above. 

20 14. As for claim 5, Osborn discloses each and every limitation of claim 1. An article of 

21 manufacture comprising a computer usable medium having computer readable program 

22 code means embodied therein for causing generation of a Concrete Model, the computer 

23 readable program code means in said article of manufacture comprising computer 

24 readable program code means for causing a computer to effect the steps of claim 1 

25 (Osbom discloses the system of Figures 1 and 2 to effect the steps of claim 1, see Figures 

26 land 2). 
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1 75. As for claim 6, Osbom discloses each and every limitation of claim 1. Osbom further 

2 discloses wherein the step of getting an Infrastructure Model includes an action taken from a 

3 group of actions consisting of: 



4 querying at least one knowledge subsystem entity (Osborn discloses obtaining the 

5 hardware abstract resource description by obtaining information from a hardware 

6 resource manager, see column 3 lines 28-43); 

1 The cited Osbom portion column 3 lines 28-43 reads: 

8 The hardware resource manager 18 is responsible for allocating hardware resources to 

9 system applications so that the least available and most functional of the available 

10 hardware resources 14 are not allocated until all options for using more available and/or 

1 1 less functional hardware resources for an application are exhausted. Details as to how the 

12 hardware resource manager 18 allocates hardware resources are given in co-pending 

13 application Ser. No. 09/586, 1 20 entitled Dynamic Hardware Resource Manager For 

14 Software-Defined Communications System, assigned to Motorola Corporation and 

15 incorporated herein by reference. The hardware resource manager 18 allocates hardware 

16 resources to an application based on characteristics, or attributes, of available hardware 

17 resource such as, for example, resource capabilities, name, type, flavor, shared, version, 

18 and address characteristics stored in a hardware specification maintained on the system 

19 platform 12 and updated as hardware resources are added or removed, as well as on 

20 configuration characteristics tracked and generated by a hardware resource identifier 19. 

21 The hardware resource identifier 19 of the present invention then uses this characteristic 

22 hardware resource information to generate a hardware specification, graphically illustrated 

23 as an abstract resource specification (78 in FIG. 2), that identifies hardware resource 

24 constraints and interdependencies and that is used by the hardware resource manager 1 8 

25 to designate certain of the resources 14 as allocated resources 15. 



26 querying Resource Managers (Osborn discloses obtaining the hardware abstract resource 

27 description by obtaining information from a hardware resource manager, see column 3 lines 

28 28-43), 
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1 



The cited Osbom portion column 3 lines 28-43 reads as stated above. 



2 



querying Resource Instance Services, 



querying a best practices catalog; 



4 
5 
6 



obtaining knowledge of available resource types (Osbom discloses obtaining the 
hardware abstract resource description by obtaining information on resource group 
types, see column 5 lines 52-56 and Figure 8); 



10 



7 



8 



9 



The cited Osbom portion column 5 lines 52-56 reads: 

At 184, all resource group types and boundaries are identified. Specifically, any collection 
of highly coupled hardware resources is a good candidate to be identified as a resource 
group. Also, identical sets of hardware resources are identified as identical group types. 



1 1 obtaining knowledge of resources constraints (Osbom discloses obtaining the hardware 

12 abstract resource description by obtaining information on resource group designations and 

13 other constraints inherently associated with resource attributes, see column 6 lines 3-20 and 

14 Figure 8); 

1 5 obtaining knowledge of resource capabilities (Osbom discloses obtaining the hardware abstract 

16 resource description by obtaining information on resource attributes, see column 6 lines 45-65 

17 and Figure 8); 

1 8 The cited Osbom portion column 6 lines 45-65 reads: 

19 Next, at 188 the abstract resource diagram is generated to organize the available hardware 

20 resources into the above-discussed domains and resource groups. FIG. 8 shows an 

21 exemplary abstract representation 168 of a subset of managed device resource groups for 

22 the multi-channel radio shown in FIG. 5. Each device is characterized by a list of attributes 

23 and one or more assigned association labels assigned, although only certain of the 

24 attributes and association labels are shown for ease of illustration and explanation. For 

25 example, the attribute and association labels for the transmitter port 154c in the RF 

26 resource group 126 identifies the resource as a port type resource with an RS422 flavor at 
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4 



5 



2 



3 



1 



system address /qcScc/1 1 and with a "tx," or transmitter, association. Such information 
describes the hardware resources and their connectivity using an abstract resource 
notation. The information of the abstract resource diagram generated by the systems 
designer can be easily encoded into hardware resource specification files 40 to describe all 
of the managed hardware resources and underlying interdependencies to the hardware 



6 



resource identifier 19. 



7 obtaining knowledge of infrastructure constraints (Osbom discloses obtaining the hardware 

8 abstract resource description by obtaining information on resource group designations and 

9 other constraints inherently associated with resource attributes, see column 6 lines 3-20 and 

10 Figure 8); 

1 1 The cited Osbom portion column 6 lines 3-20 reads: 

12 In order for the resource group designations to be useful to the hardware resource 

13 manager, the hardware resource identifier 19 must identify the managed devices within the 

14 resource groups. For example, the hardware resources within the dashed box in FIG. 7 are 

15 identified by the hardware resource identifier as belonging to the RF resource group 126. 

16 Therefore, if an application specification requests tightly coupled resources, they can all be 

17 allocated from the same RF resource group, such as the resource group 126. A signal may 

18 then be input through the receiver 144, pass through the modem 146 and then be 

19 transmitted through the external RF 138 by the transmitter 148. Alternatively, if the 

20 communication application could process the signal by requesting a super-circuit that 

21 required, for example both of the RF resource groups 126, 128, the signal could, for 

22 example, be input through the receiver 144 of RF resource group 126, pass through the 

23 modem 146, and then pass through the modem 158 and be transmitted by a transmitter 

24 175 of the RF resource group 128. 

25 obtaining knowledge of infrastructure capabilities (Osbom discloses obtaining the hardw are 

26 abstract resource description by obtaining information on resource attributes, see column 6 lines 

27 45-65 and Figure 8); 
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1 The cited Osbom portion column 6 lines 45-65 reads as stated above. 

2 obtaining knowledge of infrastructure best practices patterns; 

3 and any combination of these actions. 

4 16. As for claim 9, Osbom discloses each and every limitation of claim 1. Osbom further 

5 discloses a program storage device readable by machine, tangibly embodying a program of 

6 instructions executable by the machine to perform method steps for generating a Concrete 

1 Model, said method steps comprising the steps of claim 1 (Osbom discloses the system of Figures 

8 1 and 2 that comprise the steps of claim 1, see Figures 1 and 2). 

9 17. As for claim 10, Osbom discloses each and every limitation of claim 1. Osbom further 

1 0 discloses further comprising using said generating said Concrete Model to enforce a policy 

1 1 based service provider 's best practices in implementation of Service Environments in the 

12 computing utility infrastructure (Osbom discloses generating the Concrete Model to enforce the 

13 requirements needed to run. the application, see column 3 lines 1-8 and column 3 lines 1-8. 



14 The cited Osbom portion column 3 lines 1-8 reads: 

15 The application manager 16 is responsible for executing a system application, typically in 

16 response to an operator-initiated event, based on a stored application specification 34 that 

17 is associated with the application. The application specification 34 contains application 

18 object descriptions, known as virtual objects, 35 required hardware resource information 

19 and software object to hardware processor mapping information that application 

20 developers need to guarantee correct operation of system applications, and serves as 

21 common language among applications, the application manager 16 and the hardware 

22 resource manager 1 8 for specifying required and available resources during system 

23 resource allocation. 

24 The cited Osbom portion column 4 lines 15-23 reads as stated above. 
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1 18. As for claim 11, Osbom discloses each and every limitation of claim 10. Osbom 

2 further discloses wherein the best practices are encoded as patterns in a best practices 

3 catalog and used in the step of forming said Concrete Model (Osbom discloses the 

4 requirements are derived from an application object library column 3 lines, 9-12). 

5 The cited Osbom portion column 3 lines, 9-12 reads: 

6 The application manager 16 retrieves software objects 36 required to run the application 

7 from an application object library 37 (FIG. 2) based on the virtual objects 35, and loads 

8 the objects 36 onto the hardware processors 20, 22, 24 through a mapping function 

9 represented generally at 38 based on hardware resource allocation information provided 

10 by the hardware resource manager 18 and facilitated by the hardware resource identifier 

11 19. 

12 19. As for claims 12 and 22, Osbom discloses each and every limitation of claims 1 and 21. 

13 Osbom further discloses (means for) employing said Concrete Model to generate 

14 provisioning actions, said provisioning actions, when executed, create a resource 

1 5 structure that matches the description in the Concrete Model, said resource structure 

1 6 satisfies said set of requirements on new desired state of said service environment 

1 7 (Osbom discloses obtaining an abstract resource description describing virtual hardware 

1 8 resource objects and using the abstract resource description to create a matching 

19 resource structure to satisfy the requirements of the service environment, see column 3 

20 lines 60-67). 

2 1 The cited Osbom portion column 3 lines 60-67 reads as stated above. 

22 20. As for claim 13, Osbom discloses each and every limitation of claim 12. Osbom 

23 further discloses employing said provisioning to enforce a policy based service 

24 provider 's best practices in implementation of service environments in the computing 

25 utility infrastructure (Osborn discloses employing provisioning to enforce the 

26 requirements needed to run the application, see column 3 lines IS, 60-67 and column 4 

27 lines 15-23). 

28 The cited Osbom portion column 3 lines 1-8 reads as stated above. 

29 The cited Osbom portion column 4 lines 15-23 reads as stated above. 
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1 21. As for claim 14, Osbom discloses each and every limitation of claim 13. Osbom 

2 further discloses where in the best practices are encoded as patterns in a best practices 

3 catalog and used in the step of forming the Concrete Model (Osborn discloses the 

4 requirements are derived from an application object library column 3 lines 9-12). 

5 The cited Osbom portion column 3 lines 9-12 reads as stated above. 

6 22. As for claims 19 and 24, Osbom discloses each and every limitation of claims 1 and 

7 21. 

8 Osbom further discloses (means for) employing said Concrete Model to generate a 

9 Resource Manager for a composite resource (Osborn discloses that a hardware resource 

10 manager employs the application hardware resource specification and a hardware 

1 1 resource diagram, which represents a composite resource, see column 6 lines 3-20 and 

12 Figure 8, to allocate the composite resource and thereby create a resource manager for 

13 the composite resource, see column 7 lines 1-25). 

14 The cited Osbom portion column 7 lines 1-25 reads: 

15 Subsequent to generating the hardware resource diagram, the hardware resource 

16 specification 40, an application hardware resource specification 72 that is, for example, an 

17 ASCII file, is generated to describe the hardware resources required by an application. 

18 The manner in which the hardware resource specification is generated is similar to the 

19 above-described manner in which the abstract resource diagram is generated, except that 

20 not all attributes and resources assigned to the hardware resources need to be specified. 

21 FIG. 9 is an exemplary hardware resource specification generated in response to an 

22 application requiring the power PC processor 154a' as the PCI bus host, and an RF 

23 resource group including two serial RS422 ports 154b', 154c' associated with the receiver 

24 and the transmitter, two Altera 250 FPGAs 146c', 146d', and one Share processor 146a'. 

25 Further, the hardware specification 72 also dictates via the virtual RF resource group 189 

26 that the application requires all resources except for the power PC to come from the same 

27 RF resource group. The hardware resource manager 18 then parses the definitions and 

28 constraints in the application hardware resource specification 72 and matches the 

29 resources required by the application with the best available resources. For example, if the 

30 resources shown in FIG. 10 represent all available hardware resources, the hardware 
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1 resource manager 18 would allocate the available resources in the RF resource group 146 

2 as well as the power PC processor 154a having sufficient connectivity, represented by the 

3 darkened boxes, to the application. 

4 23. As for claim 23, Osbom discloses each and every limitation of claim 21. O shorn further 

5 discloses a computer program product comprising a computer usable medium having computer 

6 readable program code means embodied therein for causing generation a Concrete Model, the 

1 computer readable program code means in said computer program product comprising readable 

8 program code means for causing a computer to effect the functions of claim 21 (Osbom discloses 

9 the system of Figures 1 and 2 to effect the functions of claim 21, see Figures 1 and 2). 



10 24. As for claim 25, Osbom discloses each and every limitation of claim 1. Osborn further 

1 1 discloses where the step of generating a Concrete Model is performed by a user taken from a 

1 2 group of user 's consisting of: 

1 3 a service provider, a customer of a service provider, a company owning an IT 

14 infrastructure (Osborn discloses an application developer, see column 3 lines 1-15 and 

15 column 8 lines 12-23), and a utility provider (Osbom discloses an application developer, 

16 see column 3 lines 1-15 and column 8 lines 12-23). 

17 The cited Osbom portion column 3 lines 1-15 reads as stated above. 

1 8 The cited Osbom portion column 8 lines 12-23 reads: 

19 Also, the present invention is applicable to highly complex super-communication circuits 

20 in which multiple channels of hardware resources are allocated to a single application 

21 performing higher level sub-channel, or, in other words, multiplexed communications path, 

22 management. Specifically, the hardware resource manager enables an application 

23 developer, through use of the resource group concept, to assign sub-channel objects to the 

24 same resource group within a larger application. Examples of such super-communication 

25 circuits include bridging and simulcast/receive communications topologies. 
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1 In response, the applicants respectfully states that as stated above, exception is taken with the 

2 alleged teaching of the elements of Claims 1-6, 9-14, 19, and 21-25 by Osborn. The argument 

3 given for method claim 1, is similarly applicable to the apparatus claims. A review of all the cited 

4 portions of Osborn fails to support the teaching of any of the claims 1-25 of this application. The 

5 cited portions are copied below to show that indeed the alleged teaching of the elements of each 

6 claim are apparently not in Osborn. 

7 Thus, all claims are allowable over Osborn, even when combined with the other references cited 

8 below, for obviousness purposes. 



9 Claim Rejections -35 USC §103 

10 25. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 

1 1 obviousness rejections set forth in this Office action: 

12 (a) A patent may not be obtained though the invention is not identically disclosed or 

13 described as set forth in section 102 of this title, if the differences between the subject 

14 matter sought to be patented and the prior art are such that the subject matter as a whole 

15 would have been obvious at the time the invention was made to a person having ordinary 

16 skill in the art to which said subject matter pertains. Patentability shall not be negatived 

17 by the manner in which the invention was made. 

18 26. Claims 7 and 8 are rejected under 35 U.S.C. 103(a) as being unpatentable over 

19 Osborn, as applied to claim 1 above, and in further view of U.S. Patent Application 

20 Publication No. US2003/0208473 Al filed on January 28, 2000 by Lennon (denoted 

21 herein as "Lennon"). 

22 The cited art to Lennon, US Patent Application US2003/0208473, filed: January 28, 

23 2000, is entitled: "Browsing electronically-accessible resources". The abstract reads: "A 

24 method of browsing electronically-accessible resources using descriptions of the 

25 resources. These descriptions have descriptor components, which have attributes 

26 representative of at least two axes of access to the resources. These descriptions also have 

27 links to the corresponding resources. The method first reads the descriptions and displays 

28 a number of items (1608). Each one of these items are associated with a corresponding 

29 descriptor component of the read description that has an attribute. The method allows the 

30 browsing (1602, 1603) of the descriptions and their corresponding electronically-accessible 

3 1 resources via the links using the displayed items". 
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1 So, there is no reason to make this combination except in an attempt to find a combination that 

2 allegedly has the elements of these claims to make the claims obvious. This is hindsight which is 

3 not allowed. But, even the combination does not teach the combined elements. 

4 27. As for claim 7, Osborn discloses each and every limitation of claim 1. Osbom does 

5 not explicitly disclose, but Lennon discloses wherein the step of forming a Concrete 

6 Model includes: 

1 at least one refinement step comprised of selecting a node and replacing said node with a 

8 sub graph structure to obtain an intermediary model which is an input to a next 

9 refinement step (Lennon discloses selecting the description object in a resource 

10 description, see DDF on page 9 paragraphs 115 and 116, and replacing it with a sub 

1 1 tree structure, see Figure 5, to produce a description object model, see page 11 

12 paragraphs 154-156 and Figures 2 A and 2B); 

1 3 repeating the step of selecting and replacing until a resulting intermediary model is 

14 mappable to said knowledge subsystem (Lennon discloses the description object model, 

15 or DesOM, represents resources and resource relationships mappable to the system, see 

16 page 11 paragraphs 154-156 and Figures 2 A and 2B). It would have been obvious to one 

17 of ordinary skill in the art at the time of the invention to modify Osbom 's disclosure of 

1 8 forming a Concrete Model and of a description of resources (Service Environment 

19 Model) to include refining the description of resources to produce a Concrete Model in 

20 order to provide a consistent method of describing resources and thereby utilizing 

21 resource descriptions, see page 1 paragraph 6 of Lennon. 

22 The cited Lennon portion page 9 paragraphs 115 reads: 

23 [0115] The preferred DDE attempts to incorporate the benefits of declarative description 

24 of content with procedural methods for the creation and processing of descriptors. It 

25 comprises an object model, an API for the processing of descriptions, and a serialisation 

26 syntax. The DDF can be used to adequately describe content using these components. 

27 The cited Lennon portion page 9 paragraphs 116 reads: 

28 [0116] The object model provides the core semantics of the description and is based on 

29 the descriptor entity. This model has the advantage that the containment relationship is 

30 inherent in the model. This containment relationship is particularly important in the 

3 1 description of audiovisual resources for two reasons. First, the structure of many 

32 audiovisual resources has an inherent hierarchical structure (eg., a video clip contains 

33 shots which contain key frames, etc.). Second, the representation values for many 
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1 descriptors can be complex datatypes that can be represented in a hierarchical fashion (eg., 

2 a histogram contains bins which contain frequencies). The object model of the preferred 

3 DDF is called the Description Object Model DesOM). It is discussed in Section 2.2. 

4 The cited Lennon portion page 1 paragraph 6 reads: 

5 [0006] If a consistent method of describing resources can be achieved then consistent 

6 methods of selecting resource descriptions from formulated queries can be contemplated 

7 28. As for claim 8, Osborn and Lennon in. combination disclose each and every 

8 limitation of claim 7. Lennon further discloses wherein said step of replacing comprises a 

9 limitation taken from a group of limitations consisting of: querying a best practices 

1 0 catalog; generating sub graph patterns dynamically; employing graph matching 

1 1 techniques to obtain said sub-graph structure (Lennon discloses matching the sub tree 

12 structure to the description object, sec page 11 paragraph 155 and Figure 5); 

13 The cited Lennon portion page 11 paragraph 155 reads: 

14 [0155] For a description to conform to the preferred DDF, the root of the DesOM must 

15 be a Description object. In other words, the root must specify the resource to which the 

16 description refers. Since a Description object is just a specialisation of the Descriptor 

17 object, any Description object can become a sub-tree of another Description object. In 

18 other words, a new Description object can be created from a set of related Description 

19 objects. This process is shown in FIG. 5. 

20 employing graph merging techniques to obtain said sub-graph structure (Lennon 

21 discloses merging the sub tree structure to the description object, see page 11 paragraph 

22 755 and Figure 5); 

23 The cited Lennon portion page 11 paragraph 155 reads as stated above. 

24 any combination of these limitations. Lt would have been obvious to one of ordinary skill 

25 in the art at the time of the invention to modify Osborn 's disclosure of forming a 

26 Concrete Model and of a description of resources (Service Environment Model) to 

27 include refining the description of resources to produce a Concrete Model in order to 

28 provide a consistent method of describing resources and thereby utilizing resource 

29 descriptions, see page 1 paragraph 6 of Lennon. 
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1 29. Claims 15 and 16 are rejected under 35 U.S.C. 103(a) as being unpatentable over Osborn, 

2 as applied to claim 12 above, and in further view of U.S. Patent No. 6, 332, 023 Bl issued on 

3 December 18, 2001 to Porter et al. (denoted herein as "Porter"). 

4 The cited art to Porter, US Patent 6,332,023, filed: June 4, 1998, is entitled: "Method of 

5 and system for providing services in a communications network". The abstract reads: "A 

6 system for providing services in a communications network includes a service processing 

7 function, a universal directory function, and a nodal resource manager. The service 

8 processing function receives service requests, formulates requests for interworking 

9 functions based upon service requests, and formulates resource requests based upon 

10 service requests and interworking functions. The universal directory function receives 

1 1 addresses from the service processing function and returns interworking functions based 

12 upon addresses. The nodal resource manager receives resource requests and allocates 

13 resources to the service processing function in response to resource requests. The nodal 

14 resource manager maintains a resource database that includes an entry corresponding to 

15 each network resource managed by the nodal resource manager.". 

16 30. As for claim 15, Osborn discloses each and every limitation of claim 12. In addition, 

17 Osborn and Porter in combination disclose wherein step of provisioning includes a task 

1 8 taken from a group of tasks consisting of: 

19 creating a new service environment (Osborn discloses allocating resources to an 

20 application to create a service environment, see column 3 lines 60-67), 

21 changing the combination of resources allocated to a service environment (Osborn 

22 discloses allocating resources to an application to create a service environment, see 

23 column 3 lines 60-67. 

24 The cited Porter portion column 3 lines 60-67 reads: 

25 Every resource manager has a domain, which is the set of resources managed by the 

26 resource manager. The domain of a nodal resource manager is the set of resources 

27 available to a network node, as the network is currently configured. The system of the 

28 present invention may include a network resource manager, whose domain is all 

29 connective resources of the network. The network resource manager can reconfigure the 

30 network and allocate additional network resources to a nodal resource manager. In the 
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1 event a nodal resource manager cannot satisfy a resource request, the nodal resource 

2 manager may request additional resources from the network resource manager. 

3 BRIEF DESCRIPTION OF THE DRAWINGS 

4 FIG. 1 is a block diagram of a communications network according to the present 

5 invention. 

6 FIG. 2 is a block diagram of a network node according to the present invention. 
7 

8 In addition, Porter discloses de-allocating resources allocated to a service environment, 

9 see column 3 lines 40-50), 

10 The cited Porter portion column 3 lines 40-50 reads: 

1 1 Preferably, the evaluation function ranks unallocated candidate resources higher than 

12 allocated candidate resources. However, occasionally the best candidate may already be 

13 allocated to a lower priority service processing function. In those situations, the resource 

14 manager de-allocates the best candidate resource and notifies the earlier service processing 

15 function that its use of the resource has been preempted. Then the resource manager 

16 reconfigures the resource and allocates the resource to the higher priority service 

17 processing function. 

1 8 changing the configuration of resources all Ocated to a service environment (Porter 

19 discloses changing the configuring of a resource that has been allocated to a service 

20 environment, see column 3 lines 30-40), or destroying a service environment, or any 

21 combination of the above. It would have been obvious to one of ordinary skill in the art 

22 at the time of the invention to modify Osbom 's disclosure of provisioning to include the 

23 ability to change the configuration of resources in order to provide for a more flexible 

24 allocation of resources, see column 2 lines 35-54 of Porter. 

25 The cited Porter portion column 2 lines 35-54 reads: 

26 The approach of the '075 patent cannot optimize the path subject to instantaneous changes 

27 in the network or based upon per-resource cost metrics. More generally, the '075 patent 
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1 continues to confound service and addressing functions within a single database. As in 

2 traditional telephony, there is no recognition of the need to segregate service logic and 

3 addressing data. Furthermore, the approach of the '075 patent cannot effectively serve new 

4 types of traffic or services that may require flexible allocation of intervening resources, 

5 such as store-and-forward devices. 

6 There is a need for a flexible routing technique in a telecommunications network that 

7 encompasses more than a fixed mapping of numbers to trunk groups, or a fixed mapping 

8 of origination information to network resources. A new routing technique is required that 

9 takes into account many factors in routing a call and it can be applied in a multi-purpose 

1 0 communications network, rather than just for telephony. 

1 1 31. As for claim 16, Osbom and Porter in combination disclose each and every limitation of 

12 claim 15. Porter further discloses wherein changing the configuration of resources allocated to 

13 a service environment include: 

14 changing the local state of a resource (Porter discloses updating static and dynamic 

15 resource attributes, see column I lines 66-67, column 3 lines 1-20), or changing the way 

16 the resource is configured to work with other resources. It would have been obvious to 

17 one of ordinary skill in the art at the time of the invention to modify Osbom 's disclosure 

18 of provisioning to include the ability to change the configuration of resources in order to 

19 provide for a more flexible allocation of resources, see column 2 lines 35-54 of Porter. 

20 The cited Porter portion column I lines 66-67 reads: 

21 Although the traditional routing table approach has sufficed for traditional telephone use 

22 under normal conditions, it has become inadequate to accommodate new types of services 

23 and traffic. 

24 The cited Porter portion column 3 lines 1-20 reads: 

25 The present invention provides a method of and a system for providing services in a 

26 communications network. The system includes a service processing function, a universal 

27 directory function, and a resource manager. The service processing function receives 

28 service requests, formulates requests for interworking functions based upon service 
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1 requests, and formulates resource requests based upon service requests and interworking 

2 functions. The universal directory function receives logical addresses from the service 

3 processing function and returns interworking functions based upon addresses. The 

4 resource manager receives resource requests and allocates resources to the service 

5 processing function in response to resource requests. The resource manager accesses and 

6 updates a resource database that includes an entry corresponding to each network 

7 resource managed by the resource manager. 

8 Each entry of the resource database includes a resource identifier, a set of static attributes, 

9 and a set of dynamic attributes. A resource identifier uniquely identifies a resource. Static 

10 attributes are relatively stable data about the type and configuration of the resource. 

1 1 Dynamic attributes are changing data about the resource that are tracked by the resource 

12 manager, including such data as whether the resource is being used, and if so, by whom. If 

13 a resource is allocated, the dynamic attribute of the resources will include an indicator on 

14 how to find the priority of the allocation. This is because the priority of an allocation could 

15 be dynamic, i.e., the function owning a resource may assign varying priority during the 

16 duration of the allocation, or static, i.e., the priority is determined at allocation time and is 

17 fixed, so that it can be stored in the resource. 

18 The cited Porter portion column 2 lines 35-54 reads as stated above. 

19 32. Claims 17 and 18 are rejected under 35 U.S.C. 103(a) as being unpatentable over 

20 Osbom, as applied to claim 1 above, and in further view of U.S. Patent Application 

2 1 Publication No. US2004/01 28397 Al filed on September 10, 2003 by Glasmann et al. 

22 (denoted herein as "Glasmann "). 

23 The cited art to Glasmann, US Patent Publication No. US2004/0128397, filed: September 10, 

24 2003, is entitled: "Method for checking transmission resources of a packet-oriented 

25 communication network when there are topology changes". The abstract reads: 

26 "To check transmission resources of a packet-oriented communication network on a 

27 topology change, a resource manager checks a reservation of the transmission resources 

28 based on the topology data relating to the topology of the communication network. Upon 

29 a topology change of the communication network, topology change information is 
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1 transferred to the resource manager. The resource manager records new topology data 

2 which relates to the changed topology of the communication network. Based on the new 

3 topology data, the resource manager maps an existing reservation of the transmission 

4 resources to the changed topology of the communication network.". 

5 33. As for claim 1 7, Osbom discloses each and every limitation of claim 1. Osbom does 

6 not explicitly disclose, but Glasmann discloses regenerate provisioning instructions 
1 whenever at least one of the following occurs: infrastructure characteristics change 

8 (Glasmann discloses allocating resources when there is a change in the topology, see 

9 page 1 paragraph 5, 8, and 9), and requirements of a service change. It would have been 

10 obvious to one of ordinary skill in the art at the time of the invention to modify Osbom 's 

1 1 disclosure of provisioning resources to include providing resources when infrastructure 

12 characteristics change in order to provide for adaptive resource checking and reacting to 

13 topology changes (see page 1 paragraphs 7 and 10 of Glasmann). 

14 The cited Glasmann portion page 1 paragraph 5, 8, and 9 reads: 

15 [0005] In practical operation of a communication network this topology can occasionally 

16 change. Such a topology change can for example be caused by an administrative 

17 configuration change or by a failure or a recovery of a network component. As a result 

1 8 can there can be a dynamic change of communication routes in the communication 

19 network on Layer 2 (e.g., through so-called spanning-tree procedures) and/or Layer 3 

20 (e.g., by routing procedures such as RIP or OSPF) of the OSI reference model. 

21 [0008] To check transmission resources of a packet-oriented communication networks on 

22 topology changes a resource manager is provides which checks an reservation of the 

23 transmission resources in particular by connections, on the basis of the topology data 

24 relating to the topology of the communication network. A topology change in this 

25 document is also taken to mean changes to a network configuration or changes to 

26 operating conditions of the communication network. In accordance with the invention, as 

27 a result of a change to the topology of the communication network topology change 

28 information is sent to the resource manager. As a result the resource manager is caused to 

29 create new topology data relating to the changed topology of the communication network. 

30 On the basis of the new topology data created the resource manager maps an existing 
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1 



reservation of the transmission resources to the changed topology of the communication 



2 



network. 



4 



3 



[0009] A significant advantage of the invention lies in the fact that the resource manager 
can detect at an early stage and react to topology changes which as a rule result in a 



7 



5 



6 



temporary inconsistency of a topology image present in the resource manager with the 
current topology of the communication network. By mapping the existing reservation of 
resources to the changed topology resource guarantees can be maintained for the 



10 



8 



9 



connections which existed before the topology change, provided that can be combined 
with the new topology. In addition the transmission resources available after the change 
can be used particularly efficiently. 



1 1 34. As for claim 18, Osbom and Glasmarm in combination disclose each and every limitation of 

12 claim 17. Glasmarm further discloses wherein the infrastructure characteristics include a 

13 characteristic taken from a group of characteristics consisting of: types of resources in the 

14 infrastructure, capabilities of said resources (Glasmann discloses topology changes include 

1 5 changes in the capabilities of a resource, see page 1 paragraphs 4 and 5), 

16 The cited Glasmann portion page 1 paragraphs 4 and 5 reads: 

17 [0004] To be able to establish whether transmission resources requested for a connection 

18 are available on the primary route of this connection through the communication network 

19 the resource manager needs information about the topology of the communication 

20 network, i.e. about the networking structure of the network nodes and link lines and about 

21 their relevant transmission capacity. This type of topology information which specifies the 

22 topology of a communication network is frequently referred to as a topology image. 

23 [0005] In practical operation of a communication network this topology can occasionally 

24 change. Such a topology change can for example be caused by an administrative 

25 configuration change or by a failure or a recovery of a network component. As a result 

26 can there can be a dynamic change of communication routes in the communication 
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1 network on Layer 2 (e.g., through so-called spanning-tree procedures) and/or Layer 3 

2 (e.g., by routing procedures such as RIP or OSPF) of the OSI reference model. 

3 configuration of said resources (Glasmann discloses topology changes include changes 

4 in the configuration of a resource, see page 1 paragraphs 4 and 5), 

5 constraints on configuration of said resources, best practices patterns as defined in the 

6 best practices catalog, and any combination of the above. It would have been obvious to 
1 one of ordinary skill in the art at the time of the invention to modify Osbom 's disclosure 

8 of provisioning resources to include providing resources when infrastructure 

9 characteristics change in order to provide for adaptive resource checking and reacting to 

10 topology changes (see page 1 paragraphs 7 and 10 of Glasmann). 

1 1 The cited Glasmann portion page 1 paragraphs 4 and 5 reads as stated above. 

12 The cited Glasmann portion page 1 paragraphs 7 and 10 reads: 

13 [0007] An object of this invention is to specify a method of checking transmission 

14 resources of a packet-oriented communication network which allows adaptive resource 

1 5 checking when the topology of the communication network changes. 

16 [0010] Advantageously the resource manager can temporarily change over to a static 

17 resource reservation mode as a result of receiving the topology change information. In the 

18 static resource reservation mode the transmission resources are reserved preferably in 

19 accordance with a method independent of the reservation of the transmission resources or 

20 of dynamic changes to the topology image or the topology data. 



21 35. Claim 20 is rejected under 35 U.S.C. 103(a) as being unpatentable over Osbom, as applied 

22 to claim 19 above, and in further view of U.S. Patent No. 6,901,446 B2 filed on February 28, 

23 2001 by Chellis et al. (denoted herein as "Chellis "). 



24 
25 



The cited art to Chellis, US Patent 6,901,446, filed: March 14, 2005, is entitled: "System and 
method for describing and automatically managing resources". The abstract reads: "A system and 
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1 method for automatically allocating resources is provided. The system includes one or more 

2 components for automatically allocating one or more resources, based at least in part on data 

3 associated with the one or more resources, the data including at least one of, type data, instance 

4 data, characteristic data, and dynamically modifiable metadata. An alternative aspect of the system 

5 provides one or more components for automatically allocating one or more resources distributed 

6 on a plurality of resource allocation servers. The one or more components for automatically 

7 allocating the one or more resources can improve utilization of the capacity of the one or more 

8 resources. In an alternative embodiment the system includes an Application Programming 

9 Interface (API) operable to configure and/or control the one or more components for 
10 automatically allocating one or more resources". 



1 1 36. As for claim 20, Osbom discloses each and every limitation of claim 19. Osbom does 

12 not explicitly disclose, but Che I lis discloses wherein said Resource Manager provides a 

1 3 set of resource manager methods taken from a group of resource manager methods 

14 consisting of: 

1 5 creating composite resources based on a Concrete Model (As mentioned above, Osbom 

16 does disclose a resource manager for a composite resource. However, Osborn does not 

17 explicitly disclose, but Chellis discloses a resource manager capable of creating a 

1 8 composite resource, or set of interdependent resources, based on defined resource 

19 requirements for a service, see column 3 lines 36-59), 

20 changing composite resources based on a Concrete Model (As mentioned above, Osbom 

21 does disclose a resource manager for a composite resource. However, Osbom does not 

22 explicitly disclose, but Chellis discloses a resource manager capable of changing a 

23 composite resource, or set of interdependent resources, based on defined resource 

24 requirements for a service, see column 3 lines 36-67 column 4 lines 1-27 and column 9 

25 lines 55-67), 

26 The cited Chellis portion column 3 lines 36-67 reads: 

27 The present invention includes initially defining resource requirements for a service. The 

28 operation of the present invention includes the ability to redefine resource requirements, 

29 allocation rules and algorithms to more efficiently utilize resources available to be 

30 allocated. The resources to be allocated can change in numbers, characteristics and types. 

3 1 Further, the mix of resources required for an application and/or service can change. Thus, 

32 the present invention provides a system and method for defining resources, for 

33 manipulating the pool of resources available (e.g., adding/subtracting resources 
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1 dynamically based on usage), for tracking the resources available and for defining and 

2 managing dependency relationships between applications, sessions and/or resources. By 

3 way of illustration, a new resource type can be created, with the creation including 

4 recording information concerning the new resource type (e.g., disk capacity, disk speed, 

5 number of concurrent users). Similarly, an existing resource can have its characteristics 

6 change (e.g., bandwidth increased/deer eased, disk size increased/decreased). By way of 

7 further illustration, instances of a type can be added to the pool of resources available for 

8 allocation, and once added to the pool, the status (e.g., availability, online/offline, 

9 allocated/not-allocated) of the resource can be tracked. 

10 Dependencies can exist between items including, but not limited to, services and 

1 1 resources. For example, a first consumer access to a first service may require allocating a 

12 first resource and a second resource, while a second consumer access to a second service 

13 may require allocating a first resource, a second resource and two instances of a third 

14 resource. Further, there may be dependencies between resources. For example, to allocate 

15 a first resource may require that a second resource and a third resource be available to be 

16 allocated. For example, a router resource may require that a data communication channel 

17 resource and a data security resource be available before the first resource can be 

18 allocated. In the present invention, a resource may be defined so that a service is a 

19 resource to another service. For example, a database lookup service may be a resource 

20 required by an email service and a chat room service. 

21 The cited Che I lis portion column 4 lines 1-27 reads: 

22 Dependencies can exist between items including, but not limited to, services and 

23 resources. For example, a first consumer access to a first service may require allocating a 

24 first resource and a second resource, while a second consumer access to a second service 

25 may require allocating a first resource, a second resource and two instances of a third 

26 resource. Further, there may be dependencies between resources. For example, to allocate 

27 a first resource may require that a second resource and a third resource be available to be 

28 allocated. For example, a router resource may require that a data communication channel 



DOCKET NUMBER: YOR92004-0003US1 



37/39 



Serial No.: 10/776,297 



1 resource and a data security resource be available before the first resource can be 

2 allocated. In the present invention, a resource may be defined so that a service is a 

3 resource to another service. For example, a database lookup service may be a resource 

4 required by an email service and a chat room service. 

5 The data concerning resources can include data (in the form of properties and/or attributes 

6 about the resource and metadata (data about data)). The data concerning a resource can 

7 include type and relationship data. For example, a resource can be generally characterized 

8 by data including, but not limited to, its name, capacity in units relevant to the resource 

9 (e.g. megabytes, CPU cycles or transactions per second), operating characteristics, 

10 relationships with other resources, and dependencies on other resources. An instance of a 

1 1 resource may be more particularly characterized by data including, but not limited to, its 

12 allocation status, its availability, and its current allocation to services and/or resources. 

13 The metadata concerning a resource can include data about how to define a resource. For 

14 example, a resource definition may require registering N fields, (N being an integer), 

15 where a first field requires a string of M characters, (M being an integer), the characters 

16 corresponding to a resource name, where the second field requires a thirty-two bit globally 

17 unique identifier (GUID), and so on. 

1 8 and column 9 lines 55-67), 

1 9 destroying composite resources based on a Concrete Model, and any combination of 

20 these methods. It would have been obvious to one of ordinary skill in the art at the time 

21 of the invention to include in Osbom 's disclosure of a resource manager the ability to 

22 create and change composite resources in order to provide increased functionality to the 

23 resource manager and, in addition, to provide for more robust allocation of composite 

24 resources (see column 2 lines 44-67 and column 3 lines 1-6). 



25 In response, the applicants respectfully states that the various combinations of art fail to make any 

26 of the claims obvious, since they all are combined with Osborn which fails to teach even the 

27 independent claims. 

28 It is anticipated that this brings claims 1-25 as amended to allowance. 
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2 Respectfully submitted, 

3 By: /Louis Herzberg/ 

4 Dr. Louis P. Herzberg 

5 Reg. No. 41,500 

6 Voice Tel. (845)352-3194 

7 Fax. (845)352-3194 



8 3 Cloverdale Lane 

9 Monsey, NY 10952 

10 Customer Number: 54856 
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